Running MGIF as a GEM program requires the program to have an extension
of .PRG or .GTP (for newer TOS versions). For now don't worry about if
there are any differences between those two.
- Change to the directory where you unpacked the MGIF archive.
- If your computer does not recognize .GTP as a program extension (the
MGIF_5.GTP icon is of document type rather than program type), rename
the program file from MGIF_5.GTP to MGIF_5.PRG.
- Double click MGIF_5.GTP/PRG.
- If MGIF is still a .GTP program, push the 'OK' button or press enter
in the dialog that appears.
After a short while MGIF is up and running and presents you with its
startup dialog. For the time being, just click the 'OK' button or press
enter here.
MGIF will now present its @{"menu" LINK "MGIF menus"} line.
@{"Load" link "File menu" "Load file"} under the File heading in the 'File' menu will give you the
normal file selector, which can be used to find the image file you want
to load.
If you have done everything as described above, the image you select
will be loaded, converted to greyscales and drawn on the screen.
If the image was not drawn automatically, you must have done something
to cause MGIF to load the wrong (or no) options file. In that case,
select @{"Source" link "Image menu" "Draw source"} under the Draw heading in the 'Buffers' menu to tell MGIF
to display the image.
Press the left mouse button once or twice to return to the menu.
Now, try some of the image processing operations in the menu.
Documentation can be found under 'MGIF menus' in the ST-guide manual.
One thing to note about the image processing operations is that they
operate on a source and give a destination image. There are two
separate draw selections in the menu that show either of the images.
You can make source and destination the same by changing the setup in
the 'Buffers' menu.
@endnode
@node "General overview"
@{B}General overview@{0}
History
Ideas
Differences from other image viewers/processors
@{"What's new in MGIF v5.01?" link "What's new?"}
@{B}Major changes since pre-v5 MGIF@{0}
MGIF v5 is by far the most extensive update yet (and hopefully ever)
of the program. Some of the image processing and low level stuff is
about all that is left internally of the previous versions.
The most obvious new feature is of course the GEM interface, but even if
that took quite a long time to put together, it's a very small part of
the new code.
Handling of images in mapped and 24 bit colour is in my opinion the most
important improvement, coupled with the ability to show these images
with good quality, at least on the more advanced Atari computers.
Other changes include GIF/Targa/PPM save and scrollable image view.
One of the latest additions, 8 bit colour VDI support, is also quite
significant, since it's a first step towards a completely GEMified MGIF.
For a complete, but not very readable, account of the changes to MGIF
from the beginning of time, refer to the enclosed file 'HISTORY.TXT'.
@endnode
@node "History"
@{B}History@{0}
William Rosenkranz
The text below was given in answer to an email I (Johan) sent.
Any incoherency is due entirely to my editing.
I Initially wrote MGIF for the following reasons:
- I was interested in learning about F-S dithering
- I was also interested in image processing techniques
- I was starting to collect .gif images and had no way to
view them on a monochrome monitor (which is normally
what I use, though I also had/have a color monitor)
- It seemed like an interesting project as diversion and
had a practical result
I forget when it all started. It should be burried in the source code.
probably about 1990 or so. [Version 1.0 was released in December 1990]
The key was the screen switching scheme (flicker). I forget where I got
that, but I cited the developer of the technique (also in the source).
[The originator was Klaus Pedersen, unfortunately unavailable per email]
Once I had that working, I had a crude .gif viewer. After that, it was a
relatively simple matter to add some basic image processing techniques
and expand the program to also read .pi* images. I stopped development
when I was personally satisfied that I had a reasonably complete system
for whatever needs I might have. I think the code was designed with
enough flexibility to expand (which is clearly proven by your efforts).
I suppose the main thing was simplicity. That and I could not get the
flicker thing working well enough in a GEM window (ie, without line-A).
A full GUI would have been nice, and I had some slick things like pop-up
menus that I had developed earlier to plug in. But it never panned out
for me. I would probably say that MGIF under my tenure was pretty much a
hack, though I think I designed it and commented it well enough for
continued development. I.e., it was pretty modular and easy to add
functionality (image processing, new file formats, etc.).
Johan Klockars
My involvement in the MGIF project was quite unintentional from the
beginning. I'd liked the program very much since it first appeared on
the internet, but I thought it was a bit too slow. Since the sources
were available, I set about making them compatible with GNU C, which was
then, and still is, the very best C compiler that runs on an Atari (and
just about everything else).
Along the way I cleaned up the memory handling a bit and rewrote the
GIF decoder, and suddenly I had a @{B}much@{0} faster MGIF. Hurray!
Some time later there was a discussion of various compilers on the
Usenet atari group. The TurboC compiler was claimed by several people
to be the best, which I could not believe. To prove my point I ported
MGIF version 3.5 to TurboC (very simple then since it was all text
based) and posted a comparison of the original MGIF, compiled by
Sozobon C, and my slightly modified version compiled by GNU C and
TurboC. The results showed quite clearly that GNU C was/is a much
better compiler than TurboC, but it also became clear that quite a few
people liked MGIF as much as I did and wanted to have the new, faster,
version. A short discussion with Bill ended with me taking over the
development.
What happened after that, you can see for yourself.
@endnode
@node "Ideas"
@{B}Some of the ideas behind MGIF@{0}
@{B}Image processing@{0}
From the very beginning, MGIF has had its emphasis towards image
processing, rather than the usual image display functionality. One of
the more obvious artifacts of this is the relatively small number of
image file formats supported.
The source/destination concept is convenient for image processing, but
it can be extremely wasteful for viewing only purposes. It is possible
to use MGIF with a single image buffer, but then there will be some
restrictions.
@{B}Flicker for greyscales@{0}
As William Rosenkranz says in his part of the 'History' section, one of
the important reasons behind the first versions of MGIF was that there
was no way to view GIF images in any reasonable quality on a monochrome
Atari monitor. He, as well as many others, liked the paper whiteness and
the high resolution, but still wanted to look at pictures sometimes.
The idea of flickering several, specially drawn, images to give an
appearence of greyscales (by Klaus Pedersen), worked very well and has
been a corner stone of MGIF ever since.
FreeWare
This text got quite long and was put on a page of its own for easier
multiple access. Just click on the title above to read it.
It's perhaps a bit philosophical, but I'd appreciate if you read it.
It won't take very long and it discusses a few points I feel quite
strongly about.
@endnode
@node "Differences"
@{B}How MGIF differs from some other software@{0}
It might be useful to give a short overview of how MGIF differs from the
more common (right now ;-) image processing/viewing programs, such as
'GEMView' and 'Speed of Light'.
@{B}Positive@{0}
- MGIF is free!
Not only without cost, but you can also get hold of the complete
source code for use in your own FreeWare (or similar) programs.
- MGIF is fast.
For many things MGIF is a lot faster than 'GEMView' and 'Speed of
Light'. GIF loading and drawing are two major things.
To be fair, there are things that MGIF is quite a bit slower at than
for example 'Speed of Light'. JPEG loading is one thing.
- MGIF is better suited to image processing.
I know that some people (no names) have other opinions on this, but
my main reason for saying this is:
MGIF can store images internally in a format that means that no
information is lost. If a 24 bit image is converted to 256 colours
on loading, you can lose a @{B}lot@{0} of information.
@{B}Negative@{0}
- MGIFv5 will not work (see below) on any 16/24 bit graphics card.
Neither will 'Speed of Light', but 'GEMView' is very good at it.
(The new -vdi switch may work, but I have no way of testing it.)
- MGIF uses no tricks to get better colour display
'Speed of Light' has its flickering, which can be quite good in a
16 colour mode and then there are programs like 'PhotoChrome' that
changes @{"palette" link "Palette"} on the fly, giving marvelous output on a simple ST.
@endnode
@node "FreeWare"
@{B}FreeWare@{0}
@{B}Programming for fun@{0}
A very important reason for writing FreeWare programs is in my opinion
that you can do it only because it's fun. There are never any paying
users to consider when you decide on what to implement and when (if
ever) to release new versions.
The amount of work that I've put into making MGIF what it is today, and
on top of that the work of William Rosenkranz before me and a couple of
other people along the way, could never be repayed by ShareWare fees.
I myself for example have certainly worked more than half a year full
time on this program (and I usually work very fast ;-).
But why not even try?
Well, I'm in no way one of those 'Information wants to be free!' guys.
In fact I despise all that cyberspace nonsense.
My first contact with the internet and especially Usenet made a great
impression on me, though, with all these talented people sharing their
software as well as their knowledge and time.
The Free Software Foundation behind GNU C, C++, Emacs etc etc and many
many others, really do a lot to forward the field of computing.
MGIF and the rest of the software I've written is just my small
contribution. A simple 'thanks' to the internet/Usenet society.
Likely nothing I ever write will have any major impact, but at least I
can feel that I did what I could, and it was great fun!
@{B}Joint development@{0}
A very nice thing about programming FreeWare software is that it's much
easier to get other people involved in it. No money is being made, so
everyone can contribute however much or little they like.
Over the years, I've worked together on parts of the program with two
or three other people and it has worked quite well, even if they lived
in Germany or Finland.
If you feel you'd like to get involved, please send an @{"email" link "Johan Klockars" "email"}. :-)
@{B}Source code availability@{0}
While any FreeWare software is nice, it's in my opinion when it's free
to the degree that anyone can pick up the work and go on that the idea
really shines. I'm sure you have used software that has not been
supported for years and thought of lots of improvements that would be
@{B}so@{0} great to have. If the sources were available you could add those
things (or persuade someone else to do them, more frequently)!
This will never happen to commercial software and is also very unlikely
with regards to ShareWare.
It's my hope that more FreeWare authors on the Atari computers give away
their sources in the future. The wheel certainly has been reinvented
enough times by now.
If you retain your copyrights and give an 'eternally' valid contact
address of some kind (or simply state very clearly in the documentation
what your terms are for using the code) there should be no problem.
@endnode
@node "MGIF startup"
@{B}MGIF startup@{0}
Program modes
The startup dialog
Command line switches (also in file/environment and internal to MGIF).
@endnode
@node "Program modes"
@{B}Program modes@{0}
To take full advantage of MGIFv5 it should really be run as a GEM
program, but it is also possible to run in a totally text based
mode, for example if you are running MiNT with a shell.
Installing MGIFv5 as an application for certain file types works fine,
as does dragging image files onto the MGIF program icon in desktops with
support for that.
Normally when MGIF is run as a GEM program, a startup dialog will appear
where you can decide how you want MGIF to use its memory.
@endnode
@node "MGIF menus"
@{B}MGIF 5.00 menus & dialogs and their explanations@{0}
Desk @{"File" link "File ms"} @{"Image" link "Image ms"} @{"Buffers" link "Buffers ms"} @{"Frame" link "Frame ms"} @{"Point" link "Point ms"} @{"Area" link "Area ms"} @{"Options" link "Options ms"}
@endnode
@node "File ms" "File menu selections"
@{B}File@{0}
-- Image --
@{"Load" link "File menu" "Load file"}
@{"Save" link "File menu" "Save file"}
- @{"Palette" ignore} -
@{"Load" link "File menu" "Load palette"}
@{"Save" link "File menu" "Save palette"}
-- Conf. --
@{"Write" link "File menu" "Write configuration"}
--- Bye ---
@{"Quit" link "File menu" "Quit"}
@endnode
@node "Image ms" "Image menu selections"
@{B}Image@{0}
---- Draw -----
@{"Source" link "Image menu" "Draw source"}
@{"Destination" link "Image menu" "Draw destination"}
---- Show -----
@{"Drawn pic" link "Image menu" "Show drawn"}
@{"Info" link "Image menu" "Information"}
--- 24 bit ----
@{"Quantize" link "Image menu" "Quantize"}
@{"Draw RGB" link "Image menu" "Draw RGB"}
- Destination -
@{"UNDO" link "Image menu" "Undo"}
@{"Copy (save)" link "Image menu" "Copy"}
@{"Paste(load)" link "Image menu" "Paste"}
@endnode
@node "Buffers ms" "Buffers menu selections"
@{B}Buffer@{0}
----- Copy -----
@{"Dest -> src" link "Buffers menu" "Dest to src"}
@{"Src -> dest" link "Buffers menu" "Src to dest"}
-- Operations --
@{"Combine..." link "Buffers menu" "Combine"}
@{"Change type" link "Buffers menu" "Change type"}
---- Source ----
@{"Buffer 0" link "Buffers menu" "Source select"}
@{"Buffer 1" link "Buffers menu" "Source select"}
@{"Buffer 2" link "Buffers menu" "Source select"}
@{"Buffer 3" link "Buffers menu" "Source select"}
- Destination --
@{"Buffer 0" link "Buffers menu" "Destination select"}
@{"Buffer 1" link "Buffers menu" "Destination select"}
@{"Buffer 2" link "Buffers menu" "Destination select"}
@{"Buffer 3" link "Buffers menu" "Destination select"}
- Create test --
@{"Linear shade" link "Buffers menu" "Linear shade"}
@endnode
@node "Frame ms" "Frame menu selections"
@{B}Frame@{0}
--- Mirror ---
@{"Vertical" link "Frame menu" "Mirror"}
@{"Horizontal" link "Frame menu" "Mirror"}
---- Misc ----
@{"Scale..." link "Frame menu" "Scale"}
@{"Zoom" link "Frame menu" "Zoom"}
@{"Cut" link "Frame menu" "Cut"}
@{"Rotate" link "Frame menu" "Rotate"}
@{"Border..." link "Frame menu" "Border"}
@endnode
@node "Point ms" "Point menu selections"
@{B}Point@{0}
@{"Hist. equal." link "Point menu" "Hist equal"}
@{"Inversion" link "Point menu" "Inversion"}
@{"Log scale" link "Point menu" "Log scale"}
@{"Threshold" link "Point menu" "Threshold"}
@{"Contr. expan." link "Point menu" "Contr expan"}
@{"Brighten" link "Point menu" "Brighten"}
@{"Darken" link "Point menu" "Darken"}
@{"Gamma corr." link "Point menu" "Gamma corr"}
@endnode
@node "Area ms" "Area menu selections"
@{B}Area@{0}
----- Linear ------
@{"Convolutions..." link "Area menu" "Convolution"}
@{"Blur" link "Area menu" "Blur"}
--- Non-linear ----
@{"Lmax" link "Area menu" "Lmax"}
@{"Lmin" link "Area menu" "Lmin"}
@{"Median" link "Area menu" "Median"}
@{"Oil" link "Area menu" "Oil"}
@{"Pixelize" link "Area menu" "Pixelize"}
@endnode
@node "Options ms" "Options menu selections"
@{B}Options@{0}
@{"Load..." link "Options menu" "Load"}
@{"Display..." link "Options menu" "Display"}
@{"F-S..." link "Options menu" "F-S"}
@{"Quantize..." link "Options menu" "Quantize"}
@{"Misc..." link "Options menu" "Misc"}
-- ST-Guide ---
@{"Help" link "Options menu" "Help"}
@endnode
@node "The startup dialog"
@{B}The startup dialog@{0}
When MGIF is started as a GEM program it will display a dialog (unless
told not to by the @{"-dsu switch" link "Command line switches" "interface options"} that looks somewhat like:
-------------------------------
| Max memory used: 1234 Kb |
| |
| Use alternate / ST ram |
| |
| Flicker mode 24 bit |
| |
| Single: buffer screen |
-------------------------------
Here you can tell MGIF the amount of memory to use, where to allocate it
and how to use it. The number given as maximum should not be increased,
but can be decreased at will. The texts in single outlines are used as
switch buttons. They are selected when black and will invert if clicked.
Flicker mode: Allocate memory for three screens to enable
flickering (mono).
24 bit: Use three buffers for images -> 24 bit processing
possible.
Single buffer: Do not allocate memory for a destination buffer.
Source buffer is used as destination too.
screen: Use normal system screen for image display.
@{B}Hints on setup@{0}
Don't select flicker mode unless you really want it. In a colour mode on
a TT or Falcon030 it can use up large amounts of memory.
Some image manipulations need more than one buffer, for example
rotation.
Single screen can save quite a lot of memory, particularly on a Falcon
in high resolution colour modes.
If you select both single buffer and single screen you'll have the
largest possible buffer area, but you won't be able to load JPEGs.
I will try to fix this for greyscale and 24 bit load (950726).
@endnode
@node "File menu"
@label "Load file"
@{B}Load file@{0}
MGIF will present the normal file selector, giving as default directory
and file type that of the most recently loaded file.
Once a file has been selected MGIF will try to load and decode it into
the first buffer (or buffers if in RGB mode). At present MGIF only looks
to the file extension to decide what format is used, so if a file is
refused it may be simply because it has been given an erroneous
extension. While that is not common with image files from the internet
or BBSes, it does happen.
For more information on what image types can be loaded, load modes
and options etc, go to the 'Loading' section.
@line 5 64 0
@label "Save file"
@{B}Save file@{0}
This is used to save the image in the first buffer (or buffers if it's
an RGB picture).
Before you can give a file name, MGIF wants to know in what format
you want to save the file. It therefore presents a dialog box with
a popup menu for file types and some greyed out options. For now only
the popup menu and source/destination selection is implemented.
For most of the file types no extra information will be required, but
the IMG save will give an extra dialog.
When everything is set up, the normal file selector will be presented
and you can give whatever file name you wish.
For more information on file types etc, see 'Saving'.
@line 5 64 0
@label "Load palette"
@{B}Load palette@{0}
MGIF will load the palette file, *.PAL, that you chose using the
normal file selector, and use the colour definitions from it for the
destination buffer.
@line 5 64 0
@label "Save palette"
@{B}Save palette@{0}
MGIF will save the palette of the source buffer to the palette file,
*.PAL, that you chose using the normal file selector.
@line 5 64 0
@label "Write configuration"
@{B}Write configuration@{0}
This allows you to write a configuration permanently into the MGIF
executable file.
You can't do this for the currently set configuration, but rather an
options file will be loaded and used.
The normal file selector will be presented twice. First to select the
options file, normally MGIF.OPT, and then to select the MGIF program
file itself.
There is a limited amount of space reserved for options in the MGIF
executable, but since all comments are automatically stripped out
this is not likely to be a problem.
@line 5 64 0
@label "Quit"
@{B}Quit MGIF@{0}
This will decompress the ROM in your machine as if it was a JPEG file
and display it automatically on the screen. The resulting image depends
on the TOS version, but is usually one model of Lamborghini or another.
On a Falcon with TOS 4.01 as mine, it's a white '82 Countach LP400S!
Uh, or perhaps not... ;-)
@endnode
@node "IMG save"
@{B}Save in monochrome IMG format@{0}
MGIF will present a second dialog before you select the file name if
you got for the IMG save. Here you can select the precise size you
want for the image. Either in pixels or in cm/inches, though the
latter requires that you set the DPI correctly for your printer.
The image will be written to a file while it's being created, so the
size of your memory is no hindrance.
This is mainly intended for saving images to be included into word
processors or DTP programs for printing, which means that the normal
Floyd-Steinberg dithering used to great effect on the screen is not very
useful. For details on why, see 'Halftone'.
If the 'F-S dithering' switch is selected, MGIF will F-S dither the
image in monochrome while saving, using the parameters set in the
'@{"Options/F-S" link "Options menu" "F-S"}' dialog.
Normally the current dither matrix will be used instead.
@endnode
@node "Loading"
@{B}Loading files@{0}
MGIF can load images stored in the following file formats:
Type Extensions Comment
GIF GIF Both GIF87 and GIF89 can be loaded.
JPEG JPG, JPE The files must be of the JFIF type. Most are.
Targa TGA
PPM PPM
AIM AIM Format used by program Atari Image Manager.
PI? PI1, PI2 Atari Degas paintprogram format (unpacked).
FL FL MGIF's flicker file format.
(X)IMG IMG The normal GEM image format in colour or mono.
There is also a special internal format which can be used for temporary
image backups while doing extensive manipulations. MGIF can also load
dither and palette files.
An image is not necessarily loaded only into the source buffer.
- If the 'No grey' option in 'Misc...' is not selected, a greyscale
version is put in the destination buffer.
- Loading of some file types, such as JPEG, requires so much temporary
storage that the destination buffer and extra screen will be
destroyed.
If you use 24 bit mode, you have three source buffers.
@{B}Errors while loading@{0}
A number of errors can occur during a load, especially if you're loading
a JPEG, but for the time being they are all reported with the same
dialog.
Out of buffer space - The image was too large for the buffers.
Out of virtual memory - When loading JPEGs, MGIF will use the
destination buffer and extra screen (if
available) for some temporary information.
If this space is not enough it'll create a
temporary file in a directory named by the
environment variable TMP or TEMP.
The temporary file can be quite large.
Unknown file type - The file didn't have a recognized extension.
Bad file - The extension was incorrect.
File read error - Bad data or end of file detected.
@endnode
@node "Saving"
@{B}Saving files@{0}
Images can be saved in the GIF, IMG, Targa, PPM and flicker formats.
When you're manipulating images it can be useful to save and later
restore your destination buffer. This can be accomplished by using the
'@{"Copy (save)" link "Image menu" "Copy"}' and '@{"Paste(load)" link "Image menu" "Paste"}' functions in the file menu respectively. The
saving can also be done automatically, see '@{"UNDO enable" link "Options menu" "Misc"}'.
Copy/paste/undo is done in an internal, uncompressed, format. In 24 bit
mode all the source buffers (3) are saved.
@{B}Errors while writing@{0}
A number of errors can occur during a write, but for the time being they
are all reported with the same dialog.
Out of virtual memory - When loading JPEGs, MGIF will use the
destination buffer and extra screen (if
available) for some temporary information.
If this space is not enough it'll create a
temporary file in a directory named by the
environment variable TMP or TEMP.
The temporary file can be quite large.
File write error - Write error or disk full detected.
@endnode
@node "Image menu"
@label "Draw source"
@{B}Draw source buffer@{0}
Draw image in the source buffer onto the screen. Options selected in the
display and dither dialogs affect how the image is drawn.
@line 5 64 0
@label "Draw destination"
@{B}Draw destination buffer@{0}
Draw image in the source buffer onto the screen. Options selected in the
display and dither dialogs affect how the image is drawn.
@line 5 64 0
@label "Show drawn"
@{B}Show drawn picture@{0}
Show the previously drawn image.
This is not possible unless there are two screens, which is not the
case if the single screen option in the startup dialog was selected.
@line 5 64 0
@label "Information"
@{B}Buffer information@{0}
Use 'Buffer info' to get information on the sizes and types of images in
the buffers as well as the sizes of the buffers themselves.
@line 5 64 0
@label "Quantize"
@{B}Colour quantize@{0}
When an image has been loaded in, or converted to, 24 bit mode, it's
possible create a mapped picture by reducing the number of colours.
This can be done using 'quantize' with astounding results.
The number of colours to use and some operational parameters can be set
in the '@{"Options/quantize" link "Options menu" "Quantize"}' dialog.
If zero is chosen as the number of colours, MGIF will use whatever the
current screen mode is capable of.
The destination buffer currently @{B}must@{0} be buffer 0.
@line 5 64 0
@label "Draw RGB"
@{B}Draw RGB@{0}
If the first three buffers are of type Red, Green and Blue respectively,
for example after having loaded an image in 24 bit mode, you can draw
the image in full colour using 'Draw RGB'.
If you're not in Falcon TC mode, the image will be displayed using an
ordered dither.
In Falcon TC, the image will first be drawn quickly and then improved
using Floyd-Steinberg error diffusion dithering for each of the RGB
components.
@line 5 64 0
@label "Undo"
@{B}Undo operation@{0}
MGIF will reload the latest auto-saved destination buffer image.
This is not selectable unless the undo functionality has been enabled
from the '@{"Options/Misc" link "Options menu" "Misc"}' dialog.
@line 5 64 0
@label "Copy"
@{B}Copy (save)@{b}
Dumps the destination buffer contents into a file.
Can be used for backing up intermediate image manipulation results or
to help in complex operations.
@line 5 64 0
@label "Paste"
@{B}Paste (load)@{b}
Loads the previously @{"copied" link "Image menu" "Copy"} buffer into the destination buffer.
@endnode
@node "Buffers menu"
@label "Dest to src"
@{B}Copy dest -> src@{0}
Copy image from the destination to the source buffer.
The image type is not copied.
@line 5 64 0
@label "Src to dest"
@{B}Copy src -> dest@{0}
Copy image from the source to the destination buffer.
The image type is not copied.
@line 5 64 0
@label "Combine"
@{B}Combine source and destination images@{0}
A wide range of effects that can be produced with some creative use of
this. Apart from the obvious image blending, you can for example do
@{"unsharp masking enhancement" link "Unsharp masking"} (together with filter operations), binary
and diffuse masking and shading.
A dialog is displayed where you can select for both source and dest
- if they are to be involved at all
- if they should be negated
- what factor to multiply them by
You can also select
- what divisor to apply to the source/destination sum before storing
- if source and destination should be multiplied rather than added
- if a constant should be added to the source/destination sum/product
(after the division)
- if the result should be clipped to the 0-255 interval
(recommended for normal use)
With this dialog it is possible to set up calculations such as:
dest = source / 2
dest = source * 10 - dest * 9
dest = (source * 2 + dest * 3) / 5
dest = -source * 17 / 23 - dest * 111 / 17 + 128
dest = (source * dest) / 255
@line 5 64 0
@label "Change type"
@{B}Change buffer type@{0}
A dialog box will be presented where you can select what type you want
to change to. The source image will be converted and the result put in
the destination buffer.
@line 5 64 0
@label "Source select"
@{B}Source buffer selection@{0}
Select which buffer is to be used as the source for image processing
operations. The current selection checked.
@line 5 64 0
@label "Destination select"
@{B}Destination buffer selection@{0}
Select which buffer is to be used as the destination for image
processing operations. The current selection checked.
@line 5 64 0
@label "Linear shade"
@{B}Create a test image@{0}
The image in the source buffer is replaced by a vertical linear shading
and the one in the destination buffer by a horizontal linear shading.
While this is mostly intended for test purposes, it can also be used to
great effect with the 'combine' function.
@endnode
@node "Frame menu"
@label "Mirror"
@{B}Mirror image@{0}
Mirrors an image horizontally or vertically.
@line 5 64 0
@label "Scale"
@{B}Scale image@{0}
Scales an image to an arbitrary size, with or without @{"smoothing" link "Smooth scale/rotate"}.
A dialog box with many options is presented.
Absolute values as well as percentages can be given for vertical and
horizontal sizing. It's also possible to apply a given aspect
correction (set in the 'Display options' dialog) or to size the image
to fit the screen.
Use the 'Percentages' and 'Absolutes' radio buttons to switch between
the two representations. Note that, due to rounding errors, the numbers
can change slightly if you cycle between the two.
Before performing the scaling, MGIF will convert to absolute sizes.
@line 5 64 0
@label "Zoom"
@{B}Zoom into image@{0}
Use the mouse or the cursor keys to move around a window covering one
quarter of the image (if it fits on screen) to choose which part to
enlarge two times.
To increase mouse movement speed, hold down 'Shift' and/or 'Control'.
For cursor key movement, 'Shift' slows down and 'Control' speeds up.
'Help', 'Tab' or 'Alternate' (needs another key or mouse movement)
toggles showing of the coordinates of the upper left window corner.
To select the current position, click the left mouse button or press
'Insert', 'Return', 'Enter' or 'Space'.
To cancel the operation, click the right mouse button or press 'Undo',
'Esc' or 'Delete'.
@line 5 64 0
@label "Cut"
@{B}Cut out part of image@{0}
Cuts out a rectangular area of the image. A crosshair can be moved
around with the mouse or the cursor keys to select first the top left
corner and then the bottom right corner.
To increase mouse movement speed, hold down 'Shift' and/or 'Control'.
For cursor key movement, 'Shift' slows down and 'Control' speeds up.
'Help', 'Tab' or 'Alternate' (needs another key or mouse movement)
toggles showing of the coordinates of the upper left window corner.
To select the current position, click the left mouse button or press
'Insert', 'Return', 'Enter' or 'Space'.
To cancel the operation, click the right mouse button or press
'Clr/Home', 'Undo', 'Esc' or 'Delete'.
@line 5 64 0
@label "Rotate"
@{B}Rotate image@{0}
Rotate an image to any integer angle, counter clockwise, with or without
@{"smoothing" link "Smooth scale/rotate"}.
If the source and destination buffers are the same, only +/- 45 degrees
rotation is possible.
@line 5 64 0
@label "Border"
@{B}Add an image border@{0}
A dialog box is presented where the amount of space to be added on
every side of the image can be entered. The colour index used for the
added area can be given.
In mapped mode the colour will depend on the palette in use.
For greyscales or RGB, 0 will be black and 255 will be maximum
intensity.
@endnode
@node "Point menu"
@label "Hist equal"
@{B}Equalize the image histogram@{0}
This operation attempts to smooth out images with skewed or narrow
histograms. The intensity values are redistributed to match their
frequency of occurence.
@line 5 64 0
@label "Inversion"
@{B}Invert image@{0}
This is a bit more general than a simple digital negative. A threshold
value is needed and this is used as follows:
threshold == 0:
new[i] = 255 - old[i] Invert pixel
threshold < 0:
if old[i] < -threshold Old intensity < -threshold?
new[i] = 255 - old[i] yes, invert pixel
else
new[i] = old[i] no, don't change
threshold > 0:
if old[i] > threshold Old intensity > threshold?
new[i] = 255 - old[i] yes, invert pixel
else
new[i] = old[i] no, don't change
@line 5 64 0
@label "Log scale"
@{B}Logarithmic scaling of image intensities@{0}
Scale each pixel's value to the ratio of the logarithm of the pixel's
intensity and the maximum intensity in the image.
@line 5 64 0
@label "Threshold"
@{B}Threshold image@{0}
Change all pixels with an intensity above a given threshold intensity
to white and all those below the threshold to black.
@line 5 64 0
@label "Contr expan"
@{B}Expand image contrast@{0}
Attempts to expand the contrast of an image to cover the entire range
of 256 allowable grey scales. A threshold value is used to remove
intensity levels at the top and bottom of the histogram. The histogram
is searched from the top and bottom for the first intensity level with
more pixels than the threshold. The pixel intensities are then changed
as follows:
new[i] = 255 * (old[i] - low) / (high - low)
where [low,high] is the new contrast range.
@line 5 64 0
@label "Brighten"
@{B}Brighten image@{0}
A constant value is added to every pixel's intensity. Any new values
outside the range 0-255 are limited to these values.
@line 5 64 0
@label "Darken"
@{B}Darken@{0}
A constant value is subtracted from every pixel's intensity. Any new
values outside the range 0-255 are limited to these values.
@line 5 64 0
@label "Gamma corr"
@{B}Gamma correction@{0}
The given value is divided by ten and then used to brighten or darken
an image. Pure black and white will stay the same, but the shades in
between will be modified in a non-linear fashion.
A value of ten will keep the image unchanged, while lower values darken
and higher ones brighten it.
@endnode
@node "Area menu"
@label "Convolution"
@{B}Apply convolution filter to image@{0}
Apply one of a number of 3x3 convolutions to an image. Choose one of the
built-in filters or enter your own.
DSP code now gives @{B}very@{0} much faster operation (10x) on a Falcon.
Smoothing (low pass), edge detection (high pass), sharpening etc can
all be done using these filters.
For more information on the filters, see 'Convolutions'.
Each pixel's intensity value is changed to a value calculated by
multiplying the pixel intensities of the pixels in the surrounding 3x3
square by the corresponding factors in the convolution matrix and
summing up. A multiplier or divisor can be applied to the sum before
the result is used as the new intensity.
@line 5 64 0
@label "Blur"
@{B}Blur image@{0}
Each pixel's intensity value is changed to the mean of the pixels in
a surrounding square. The size of the square can be given.
Although any odd number can be used as side length of the square, the
3x3 square is the most useful. Special code is used to optimize the
speed of averaging such a square.
The method used to calculate the averages for non-3x3 squares is such
that the time it takes to process an image is proportional to the
length of the side rather than the area of the square.
An 11x11 square will take about twice as long as a 5x5 one, not four
times longer as would normally be expected.
@line 5 64 0
@label "Lmax"
@{B}Local maximum@{0}
Search a square of a given size for the highest intensity value and
replace the center pixel with that.
This is sometimes called erosion in other software.
For black and white images this has the effect of enlarging the white
areas. For greyscale images the effects are hard to describe, but
generally highlights become more visible.
@line 5 64 0
@label "Lmin"
@{B}Local minimum@{0}
Search a square of a given size for the lowest intensity value and
replace the center pixel with that.
This is sometimes called dilation in other software.
For black and white images this has the effect of enlarging the black
areas. For greyscale images the effects are hard to describe.
@line 5 64 0
@label "Median"
@{B}Median@{0}
Determine the median intensity value in a 3x3 square and replace the
center pixel with that.
DSP code now gives @{B}very@{0} much faster operation (5x) on a Falcon.
Useful for removing pixel noise and also for special effects.
If it's applied several times, interesting results can be had.
@line 5 64 0
@label "Oil"
@{B}Oil@{0}
Do an oilpaint alike 'smudging' of the picture.
The size of the 'smudging' square can be set as can the number of
'buckets' to use. The second number should always be a power of two
(it's rounded if needed) and is used to group together similar
intensities. With the default, 64, the intensity 'resolution' is
4 and with 16 it would be 16.
Far from all combinations of numbers work well. Experiment!
The routine searches through the square around every pixel and counts
how many there are of each intensity group. The value of the most
common group is used as new pixel value.
@line 5 64 0
@label "Pixelize"
@{B}Pixelize@{0}
Replace squares in the image with the mean value of the pixels in the
square. The size of the square is selectable.
This will give a nice looking 'mosaic' effect.
@endnode
@node "Options menu"
@label "Load"
@{B}Load options@{0}
Here you can set how images should be loaded and if anything special
should be done upon loading.
@{B}Display@{0}
Draw image directly after loading.
@{B}No grey@{0}
If this is not selected, every loaded image will be converted to
greyscales and the result put in the destination buffer, when there
is one.
@{B}Fit to screen@{0}
Size image to fit screen directly after loading.
@{B}Correct aspect ratio@{0}
Size image to correct aspect ratio directly after loading.
Grey - Images stored and displayed in greyscales.
Mapped - Images stored with their original number of colours and
drawn as well as possible in the current screen mode.
If the used graphics mode has fewer colours than the stored
image, it may not look very good at all.
JPEGs are automatically colour quantized at load time.
24 bit - The red, green and blue components of the image are stored in
separate buffers and will normally be displayed separately.
@line 5 64 0
@label "Display"
@{B}Display options@{0}
Under the display options you can select how the loaded images should
be displayed.
@{B}After processing@{0}
Display image after every successful image processing operation.
@{B}Flicker@{0}
Display greyscale images with mono flickering.
@{B}Ordered@{0}
Enable the ordered dithering when a mapped picture is displayed in a 16
colour mode or when a 24 bit picture is displayed in 256 or 16 colours.
@{B}Preview@{0}
Do quick preview first when drawing.
@{B}Center image@{0}
Images are drawn centered on the screen instead of in the upper left
corner.
@{B}Scrollable view@{0}
If a drawn image is larger than the screen, this will allow it all
to be viewed by moving the mouse.
@{B}Aspect ratio setting@{0}
Using 'options/aspect' it is possible to tell MGIF that the pixels on
your screen are not quadratic. The x/y ratio will be used when you
rotate images or if you use the aspect scale function.
You have to give the number of vertical pixels that corresponds to 100
horizontal. This number can easily be found by going into cut mode and
measuring on the screen while you move the crosshair.
@line 5 64 0
@label "F-S"
@{B}Floyd-Steinberg dithering options@{0}
The F-S error diffusion dithering can be improved by setting up and
selecting a noise addition factor and a Laplace edge detection filter.
These will not affect the image itself but the dithering process.
The options will slow the F-S dithering down quite a bit.
@{B}Laplace filter@{0}
Helps to define hard edges in images by applying a Laplace filter. A
quantity, Beta, is required. A value of one corresponds to a Beta of
0.25, a value of two corresponds to a Beta of 0.50 etc.
The same effect can be had by giving a suitable matrix to the
convolution function.
@{B}Noise@{0}
Adds noise. This can help in images which have artificial banding as a
result of the dithering process. Input value is a percentage (0 to 100).
@line 5 64 0
@label "Quantize"
@{B}Colour quantize options@{0}
The MGIF colour quantize routines (from the IJG libraries) uses two
steps:
- Select the n best colours, where n normally is the number available
in the selected graphics mode.
- Blend the colours with Floyd-Steinberg error diffusion dithering to
make it look like a lot more of them are used. This does not use the
same F-S code as the display algorithms, which is set up using
another dialog.
These steps can be selected individually using 'two pass' (If this is
not selected, a default selection of colours is used.) and 'dither'
options respectively.
The colour selection is rather quick, but the F-S dithering is slow.
Colour quantization is a very complex operation and it needs a lot of
memory. The destination buffer and the extra screen will be used and
destroyed. Read also about virtual memory and temporary files.
@line 5 64 0
@label "Misc"
@{B}Miscellaneous options@{0}
@{B}RGB mode@{0}
If this has been selected, all image manipulation functions will
operate on all three RGB components (buffers).
@{B}VDI colour order@{0}
Some colour IMG files will get incorrect colours without this selected.
@{B}UNDO enable@{0}
Tell MGIF to start saving destination buffers before operations are
performed. '@{"UNDO" link "Image menu" "Undo"}' can be used to restore the image.
@line 5 64 0
@label "Help"
@{B}Help@{0}
Tell ST-Guide to display this manual.
@endnode
@node "Image processing operations"
@{B}Image processing operations@{0}
A rough split can be done between the operations that operate on the
pixel level and those that operate on complete images.
@{B}Pixel level operations@{0}
A further split is in order here since some operations only depend on
single pixels while others use several for each operation. I'll call
the former mappings and the latter filters.
@{B}Mappings@{0}
When the change to a pixel only depends on itself and not on any of
its neighbours a simple mapping, a table lookup, can be used to perform
the operation. For all these functions MGIF does in fact calculate a
table with entries for all 256 possible intensity values and then
applies this table to all pixels in the image.
The mapping operations in MGIF are found under the @{"point" link "Point menu selections"} menu.
'Combine' and 'Change type' from the @{"buffer" link "Buffer menu selections"} menu are also more or less
mappings.
@{B}Filters@{0}
Filters depend on a surrounding of a pixel in some way. Many of the
filters in MGIF use a 3x3 surrounding box, but some can use a box of
any size you may wish. There is currently no support in MGIF for
non-rectangular surroundings, but that's very seldom a problem.
Unlike the mappings, the filter functions can not reasonably be
calculated once and for all and then applied since they, as mentioned,
depend on several pixels. For this reason these functions can often
take a while to apply. Don't worry, though, you'll only have to wait
more than a minute in extreme cases. Often ten seconds or less will
suffice.
Filters are often divided into linear and non-linear ones, depending on
what kind of operation they do on the pixels involved. Normally you will
have no reason to worry about that.
The filter operations in MGIF are found under the @{"area" link "Area menu selections"} menu.
@{B}Image level operations@{0}
These operations do not bother themselves with the actual pixels at all,
but rather with the image as a whole. The appearance of the image is
changed while (almost) nothing is done to its content.
The image level operations in MGIF are found under the @{"frame" link "Frame menu selections"} menu.
'Quantization' from the @{"image" link "Image menu selections"} should perhaps not be here, but I don't
think it fits perfectly into any of my categories, so...
@endnode
@node "Configuration"
@{B}Configuration@{0}
Command line switches
Environment
Options file
Shortcut file
Startup files
@endnode
@node "Options file"
@{B}Options file@{0}
At startup MGIF normally reads the file MGIF.OPT from the current
directory (this can be changed by the @{"-o switch" link "Command line switches" "options file"}).
In this file, any @{"command line switches" link "Command line switches"} can be given.
Everything in the options file will be interpreted as options, unless
there is a leading '#' on a row, which signifies a comment.
The position of a switch within a row is totally irrelevant.
The supplied MGIF.OPT has a couple of default switches set and all the
rest (that are useful in an auto-loaded options file) described but
disabled by a leading '#'.
Options given in a file like MGIF.OPT can be @{"written permanently" link "File menu" "Write configuration"} into
the MGIF executable.
@endnode
@node "Shortcut file"
@{B}Shortcut file@{0}
All menu items in MGIF can be selected by keyboard shortcuts, if they
are set up correctly. To make this feature as flexible as possible, all
the definitions are read from the file MGIF.KEY at startup (this can be
changed by the @{"-key switch" link "Command line switches" "key file"}).
The supplied MGIF.KEY file defines a couple of default shortcuts and
can easily be used as an example for customization.
The important parts of a definition line in the file is as follows:
- First 'word' to search for.
- Second 'word' to search for (not needed).
- Shift keys: c - Control s - Shift a - Alternate
- Key
A 'word' is either a single word or something between two double quotes.
Normally only one search 'word' is needed. This would then be the text
on the menu item in question. Sometimes that is not enough, since there
can be multiple items with the same name in different menu positions. In
those cases the second 'word' will be searched from where the first was
found. The first should then be one found at such a place as to make the
second one the correct.
Any Control/Shift/Alternate combination can be given for a shortcut.
An example:
@{"Palette" ignore},Load csP
It was not possible to give only 'Load' since that would have found the
file load item first. By looking for '@{"Palette" ignore}' at the start of the
search, the incorrect one is bypassed.
The shortcut is set to Control-Shift-P.
For the time being there is no way to use special keys such as 'ESC',
'F9', 'Help' etc as shortcut keys (950726).
@endnode
@node "Environment"
@{B}Environment@{0}
MGIF makes use of a couple of environment variables:
MGIF_OPT - Options parsed as if given on the command line.
TMP - A directory used for temporary storage.
TEMP - If the above was not available.
@endnode
@node "Startup files"
@{B}MGIF startup files@{0}
When MGIF is run it normally tries to load the following files:
1 MGIFv5.RSC Normal GEM resource file
2 @{"MGIF.OPT" link "Options file"} Various setup values etc.
3 @{"MGIF.KEY" link "Shortcut file"} Keyboard shortcut setups.
4 MGIF.DTT Ordered dither matrices.
5 MGIF_FL.EXE Program code for self-running flicker files.
The first one can be modified using any resource editor, with the same
limitations as normally applies to such things.
Number 2 and 3 can, and should, be modified to make MGIF behave in a
way that pleases you.
Number 4 can be modified, but I'd rather recommend creating a .DIT file
(the kind used by 'GEMView' and 'Speed of Light') and load that instead.
The 'GEMView' distribution contains (or at least used to) a FreeWare
program for doing that.
The last file should not be modified (unless you @{B}really@{0} know what you
are doing).
You can change where MGIF loads the last four files from using @{"switches" link "Command line switches" "Config files"}.
@endnode
@node "Definitions"
@{B}Definitions@{0}
Greyscale
Mapped colour
True colour (24 bit)
Convolutions
Unsharp masking
Spatial frequency
Histogram
Palette
Floyd-Steinberg
Ordered dither
Halftone
@endnode
@node "Greyscale"
@{B}Greyscale@{0}
Obviously an image that is represented in greyscales can have no colour
whatsoever. For every pixel the intensity is stored as an eight bit
value, 0-255. 0 is black and 255 is white.
@endnode
@node "Mapped colour"
@{B}Mapped colour@{0}
For an image that is stored in mapped colour mode, an eight bit value
for each pixel is an index into a palette of colours. Nothing can be
said from only the value.
@endnode
@node "True colour"
@{B}True colour@{0}
As the name suggests, this is the mode to use if you want to keep all
the colour in an image. Normally eight bits per colour component (Red,
Green and Blue) is deemed enough for lifelike reproduction, but that is
not really true. Unfortunately, image file formats that can handle more
than 24 bits per pixel are not very common.
Since the three intensity values for every pixel use the same number
of bits as for a greyscale one, true colour images are most often
handled as three separate greyscale pictures.
@endnode
@node "Convolutions"
@{B}Convolutions@{0}
My Oxford Advanced Learners Dictionary suggests that a convolution is a
twist or a coil, which is not much help, I guess. ;-)
Fundamentals of digital image processing gives a formula,
"the convolution of the input with the impulse response" for shift
invariant systems, which probably won't help you any more....
Let's take a few examples instead:
The blur function from the menu is rather simple to understand. Blur
calculates the average value of, by default, the nine pixels closest to
every point in the image and then replaces the middle pixel with that
